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applications, time-slots, and bearer services; 204,120 ISDN message elements can be 
formed into any distribution of ISDN message traffic. A message scale factor is used to 
sculpture this ISDN message distribution to suit the traffic load desired. 

The scenario selection process, as part of ScenGen, consists of filtering the data in the 
Traffic Model to suit a particular set of ISDN users by: 

• Selecting the cities 

• Selecting the industries 

• Selecting the applications 

• Selecting the time-slots 

• Selecting the bearer services 

• Choosing a message factor. 
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SECTION 6 


SUMMARY 


6.1 General 

This task completion report described the Traffic Model that was developed for this NASA 
SCAR effort to generate scenarios for the Interim Service ISDN Satellite (ISIS) and the 
Full Service ISDN Satellite (FSIS). The ultimate aim of this aspect of the SCAR Program 
is the design of a new advanced ISDN communications satellite. The technical and 
operational parameters for this ISDN advanced communications satellite design will be 
obtained from an engineering software model of the major subsystems of the ISDN 
communications satellite architecture. Discrete event simulation experiments will be 
performed with the model using various Traffic Model generated scenarios, technical 
parameters, and operational procedures. The data from those simulation experiments will 
be analyzed using the performance measures discussed in previous reports. 

6.2 Review 

After an introduction that provided the background and scope of this NASA SCAR 
Program, the use of modeling and simulation to determine the parameters for the advanced 
ISDN communications satellite design was presented. An overview of the modeling and 
simulation tasks included a brief description of the four software programs for the effort. 
Particular associations were made between the Traffic Model and the scenarios generated 
form it. 

Two main sections of this task completion report are Traffic Model and Scenario 
Generation Sections. The Traffic Model described each of the databases that make the 
Traffic Model. The Scenario Generation described how the Traffic Model database data 
are used to generate Scenario Traffic Files (STFs) for the network model and simulation. 
These sections were followed by a Traffic Model application section. 

6.3 Continuing Efforts 

The present Traffic Model is adequate for the ISIS and FSIS needs of the SCAR Program. 
Some research is continuing at the broadband ISDN user level of the Traffic Model that will 
be included as an update in the latter part of this effort. 
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SECTION 1 


INTRODUCTION 


1.1 Background 

The objectives of this element of the NASA Satellite Communications Applications 
Research (SCAR) Program are to develop new advanced on-board satellite capabilities that 
will enable the provision of new services, namely interim and full Integrated Services 
Digital Network (ISDN) services via satellite and to provide a system analysis of futuristic 
satellite communications concepts, namely broadband services via satellite. 

This aspect of the NASA SCAR Program provides a research and development effort to: 

1) develop basic technologies and concepts to use the on-board processing and 
switching capabilities of advanced satellites that will enable the provision of 
interim and full ISDN services and 

2) provide a systems and requirements analysis of future satellite 
communications concepts based on a new generation of broadband 
switching and processing satellites. 

These objectives will be achieved in part via modeling and simulation of ISDN 
communications satellite designs as part of the ISDN terrestrial network. Models of the 
Interim Service ISDN Satellite (ISIS) and the Full Service ISDN Satellite (FSIS) will 
exercised using discrete event simulation techniques. 

To provide meaningful results a suitable Traffic Model was devised to represent the 
anticipated ISDN user traffic. Since few ISDN users are presently available, a proper 
Traffic Model was obtained through surveys of prospective users conducted by the 
University of Colorado. 


1.2 Scope 

This task completion report documents the Traffic Model derived from the extrapolation of 
ISDN prospective user survey data. The process and methodology for using this Traffic 
Model is in the context described in Figure 1.2-1, "NASA/SCAR Approaches for 
Advanced ISDN Satellites". The Traffic Model data will be used to generate scenarios for 
network model designs that represents satellite systems like the Advanced Communications 
Technology Satellite (ACTS) orbiting switch. 

ACTS will be controlled by a Master Ground Station (MGS) shown in Figure 1.2-2, 
"Closed User-Oriented Scenario". A user of the ACTS satellite orbiting switch requests 
services from the Master Ground Station (MGS), a combination of the NASA Ground 
Station (NGS) and the Master Control Station (MCS). The MGS, in turn, commands the 
satellite to switch the appropriate communication channel. 

The ultimate aim of this SCAR Program is to consider a full on-board-processing satellite 
which is somewhat equivalent to moving these MGS functions on-board the next 
generation ISDN communications satellite as shown in Figure 1.2-3, "Advanced ISDN 
Satellite". The technical and operational parameters for the advanced 
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Figure 1.2-1 NASA/SCAR Approaches for Advanced ISDN Satellites 
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Figure 1.2-3 Advanced ISDN Satellite 





ISDN communications satellite design will be obtained from an engineering software model 
of the major subsystems of the ISDN communications satellite architecture. Discrete event 
simulation experiments will be performed with the model using various Traffic Model 
derived scenarios, design parameters, and operational procedures. The data from these 
simulation experiments will be analyzed using the NASA SCAR performance measures 
discussed in previous reports. 


1 . 3 Document Overview 

This task completion report begins by describing the use of modeling and simulation 
techniques to determine the design parameters for the SCAR advanced ISDN 
communications satellite design. Section 2. provides an overview of the modeling and 
simulation tasks including a brief description of the four software programs of that effort 

Two main sections of this task completion report are Traffic Model and Scenario 
Generation Sections. The Traffic Model, Section 3., describes each of the databases that 
make the Traffic Model. The Scenario Generation, Section 4., describes how the Traffic 
Model database data are used to generate Scenario Traffic Files (STFs) for the network 
model and simulation. 

Section 5. describes the application of the Traffic Model to specific scenarios and Section 
6. summarizes the task completion report. 
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SECTION 2 

MODELING AND SIMULATION 


2.1 Modeling and Simulation Objective 

The objective of this modeling and simulation project is to design and develop software 
models that can be used to simulate selected aspects of the ISDN communications satellite 
with sufficient fidelity to assist in its design. This end-to-end simulation will include 
sufficient functionality to demonstrate the interactions between each of the four modeling 
and simulation phases: database generation, scenario generation, simulation run, and 
product generation. 


2.2 Major Modeling and Simulation Tasks 

The major modeling and simulation tasks for this SCAR Project are depicted in Figure 2.2- 
1, "Task Flow Diagram for the SCAR Program". Each of these tasks is described in the 
following sections as an overview of the modeling and simulation process as well as to 
provide the proper context for the Traffic Model. 


2.2.1 Database Generation Program 

The Database Generation (DbGen) program assembles the major ISDN user characteristics 
into a machine readable database. For this NASA SCAR effort that database consists of the 
Traffic Model database of ISDN user characteristics. That database is an input to the 
scenario generation process. A full description of this Traffic Model database is presented 
in Section 3. 


2.2.2 Scenario Generation Program 

The Scenario Generation (ScenGen) program selects entries from the user Traffic Model 
database and engineering parameter databases to generates a list of time ordered, initiating 
discrete events. The discrete event list is call a Scenario Traffic File (STF). The STF is 
used to initialize the model for a specific ISDN communications satellite design and to 
exercise that satellite design with requests for ISDN communication services dictated by 
the Traffic Model. The use of the Traffic Model to generate appropriate ISDN 
communication scenarios is discussed in Section 4.0. 

2.2.3 Simulation Run Program 

The Simulation Run (SimRun) program consists of a model of the real world 
communications network of the major ISDN communications satellite components. For 
this NASA SCAR effort two models are envisioned, ISIS and FSIS. Models of the 
Interim Service ISDN Satellite (ISIS) and the Full Service ISDN Satellite (FSIS) will be 
exercised using discrete event simulation techniques and STFs derived from the Traffic 
Model. 


Each of these ISDN communications satellite components is represented by a block 
diagram. The SimRun program essentially reads each discrete event from the (STF); takes 
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Figure 2.2-1 Task Flow Diagrams for the NASA SCAR Program 




the appropriate action; and logs that action and the corresponding results in a measurement 
save (MSAVE) file. The appropriate action taken by the simulation includes allocating and 
releasing ISDN communications satellite resources, denying specific services, adding 
discrete events to the traffic file, and calling other processes in-tum. 


2.2.4 Product Generation Program 

The Product Generation (ProdGen) program reads the data in the MSAVE file and 
analyzes these data in accordance with specific algorithms. It is envisioned that there will 
be as many product generation programs as there are issues to be studied: throughput, 
response time, trace, delay, call blocking, busy-minute, busy-hour, etc. The performance 
measures cited in previous reports will be used as criteria to evaluate the design parameters, 
operational procedures and degree of compliance to ISDN communication standards. 
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SECTION 3 


TRAFFIC MODEL 

3.1 End-to-End Simulation Program 

The ISDN satellite end-to-end simulation is shown in Figure 3.1-1 "End-to-end Model 
Architecture". Each program is physically and functionally separated by input/output data 
files. This separation ensures that each program is independent and that each project phase 
is separate from the others. The only link between these programs is the data files they 
share. 


3.2 Traffic Model Database 

The Scenario Generation (ScenGen) program reads the Traffic Model database that 
describes potential ISDN users and the statistical information of the ISDN services 
requested. This Traffic Model consists of a number of databases: the City Reference DB, 
ISDN User vs Industry DB, Application vs Industry DB, Application vs Time DB, and 
Application vs Bearer Services DB. 

3.2.1 City Reference Database (SCAR DB1) 

This database. Table 3.2. 1-1, "City Reference Database", identifies the percentage of ISDN 
users that are associated with the population of fifty-four major cities. Due to paucity of 
specific ISDN user information this percentage factor will be used as multiplier of 
population to infer the number of ISDN users in that region. When more concrete ISDN 
user data become available that percentage factor will be adjusted accordingly. For the 
foreseeable future an average value of 3.3% of the general population are viewed as ISDN 
users. The percentage range of that ISDN user population is between 5% and 3%. 

The geographic coordinates of these of these cities together with their US time-zone are 
also included in the Traffic Model in order to provide a sub-point for communications 
satellite operations. These location data will permit the modeling of terrestrial/space 
networks that account for antenna hopping, satellite hand-over, and multiple satellite views. 
A view of the geographical distribution of these CONUS Traffic Model Cities is shown in 
Figure 3.2. 1-1, "CONUS City Locations for NASA SCAR Traffic Model Database". 
Those cities outlined with an ellipse identify the ACTS-east cities. Those cities outlined 
with a rectangle identify the "ACTS-west" cities and the blackened squares depict the fixed 
antenna cities. The east/west ACTS city clusters are separated by a dashed line. The figure 
shows that the NASA SCAR Traffic Model is well aligned with the cities of interest for 
ACTS. That Traffic Model database represents the ISDN traffic for these cities and is the 
principal input to the scenario generation process. 

3.2.2 ISDN User versus Industry Database (SCAR DB2) 

This database, Table 3.2.2- 1, "ISDN User vs Industry", apportions the ISDN traffic 
among twenty-one industries. These data permit the scenario selection on an industry-by- 
industry basis. This database in used in conjunction with the City Reference Database to 
further decompose the ISDN service use in terms of industry affiliation. The bold 
assumption made is that each city has the same industry distribution. A further Traffic 
Model refinement could add an other City vs Industry database fields which would require 
that 1130 data elements be added to the present 684 data elements. The present Traffic 
Model is deemed adequate for the present effort. 
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Figure 3.1-1 End to End ISDN Model Architecture 





Table 3.2.1-1 City Reference Database 

SCAR 7. 

1 LATITUDE 

ISDNPCT 


CITY NAME 

POPULATION 

,000 

LONGITUDE TIMEZONB 

*» *n * i 

Honolulu 

838 

21 

-157 

3.30 

-5 

Anchorage 

227 

61 

-150 

3.10 

-4 

Seattle-Tacoma 

2421 

47 

-122 

3.40 

-3 

Portland-Vancouver 

1414 

45 

-122 

3.10 

-3 

San Francisco-Oakland-San Jose 

6042 

37 

-122 

4.00 

-3 

Sacramento 

1385 

38 

-121 

3.30 

-3 

Los Angeles- Anaheim- Riverside 

13770 

34 

-118 

4.50 

-3 

San Diego 

2370 

32 

-117 

3.30 

-3 

Phoenix 

2030 

33 

-112 

3.30 

-2 

Salt Lake City-Ogden 

1065 

40 

-111 

3.10 

-2 

Denver-Boulder 

1858 

39 

-103 

3.10 

-2 

Houston-Galveston 

3641 

32 

-100 

3.40 

-1 

San Antonio 

1323 

30 

-98 

3.10 

-1 

Oklahoma City 

964 

35 

-97 

3.20 

-1 

Dallas-Fort Worth 

3766 

32 

-97 

3.40 

-1 

Kansas City 

1575 

39 

-94 

3.10 

-1 

Minneapolis-Sl Paul 

2388 

44 

-93 

3.30 

-1 

St Louis 

2467 

38 

-90 

3.20 

-1 

Memphis 

979 

35 

-90 

3.10 

-1 

New Orleans 

1307 

29 

-90 

3.10 

-1 

Milwaukee- Racine 

1572 

42 

-87 

3.10 

-1 

Chicago-Gary Lake County 

8181 

41 

-87 

3.90 

0 

Indianapolis 

1237 

39 

-86 

3.10 

0 

Nashville 

972 

36 

-86 

3.10 

-1 

Birmingham 

923 

33 

-86 

3.10 

-1 

Louisville 

967 

38 

•85 

3.10 

0 

Cincinnati-Hamilton 

1728 

39 

-84 

3.20 

0 

Dayton-Sprigfield 

948 

39 

-84 

3.20 

0 

Atlanta 

2737 

33 

-84 

3.20 

0 

Detroit-Ann Arbor 

4620 

42 

-83 

3.30 

0 

Columbus 

1344 

39 

-83 

3.10 

0 

Tampa-St Petersburg-Clearwater 

1995 

27 

-82 

3.20 

0 

Cleveland-Akron-Lorain 

2769 

41 

-81 

3.30 

0 

Jacksonville 

898 

30 

-81 

3.10 

0 

Orlando 

971 

28 

-81 

3.20 

0 

Pittsburgh-Beaver Valley 

2284 

40 

-80 

3.20 

0 

Charlotte-Gastonia-Rocky Hill 

1112 

35 

-80 

3.10 

0 

Miami-Fort-Lauderdale 

3001 

25 

-80 

3.30 

0 

Greensboro- Winston-Salem-High 

925 

36 

-79 

3.10 

0 

BuffaJo-Niagara Falls 

1176 

42 

-78 

3.20 

0 

Rochester 

980 

43 

-77 

3.20 

0 

Washington 

3734 

38 

-77 

3.30 

0 

Richmond- Petersburg 

844 

37 

-77 

3.20 

0 

Baltimore 

2342 

39 

-76 

3.20 

0 

Philadelphia-Winington-T renton 

5963 

39 

-75 

3.80 

0 

Norfok-Virginia Beach-Newport News 

1380 

36 

-74 

3.20 

0 

Hartford-New Britain-Middleton 

1068 

42 

-73 

3.00 

0 

Albany-Schenectady-T roy 

851 

42 

-73 

3.20 

0 

New York-New Jersey-Long island 

18120 

40 

-73 

5.00 

0 

Boston-Lawrence-Salem 

4110 

42 

-71 

3.30 

0 

Providence-Pawtucket-Fall River 

1125 

41 

-71 

3.00 

0 

San Juan-Caguas-Ponce, PR 

54 CowM 

550 

18 

-66 

3.20 

5j00 Mn 

3.29 Avg 

1 
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Figure 3.2. 1-1 CONUS City Locations for NASA SCAR Traffic Model Database 
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Table 3.2.2-1 ISDN User vs Industry 

SCAR Database 2 . 

ISDN 

Industry 

% 

BROADCAST 

4.0 

COMMUNICATION 

10.0 

CONSTRUCTION 

2.0 

DATA PROCESSING 

2.0 

EDUCATION 

6.0 

ENERGY 

2.0 

FINANCIAL 

8.0 

FOOD SERWICE 

2.0 

GOVERNMENT 

8.0 

LEGAL 

6.0 

LODGING 

4.0 

j MANUFACTURING 

6.0 

MEDICAL 

6.0 

MILITARY 

10.0 

PUBLISHING 

4.0 

RECREATION 

4.0 

RESIDENTIAL 

2.0 

RETAIL 

4.0 

TRANSPORT 

6.0 

UTILITY 

2.0 

WHOLESALE 

2.0 

— 

- Check 

21 Count 

100.0 Normalization 
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3.2.3 Application versus Industry Database (SCAR DB3) 

This database, Table 3.2.3- 1, "Application vs Industry Database", further apportions the 
industry into applications of communication services. This added data granularity permits 
the selection of scenarios tailored on an application basis. The nine applications are spread 
across each of the twenty-one industries on a percentage basis to permit each application to 
contribute in a normalized fashion. This normalization process provides a degree of 
comparison of communication utility among industries. The Communications Check Sum 
indicates how much aggregate communication is used by each industry. A cursory review 
of the data in Table 3.2.3- 1 reveals that the below listed user categories fall in the top and 
bottom ends of the utilization distribution as shown. 

This ranking agrees with the project participants intuitive feel and, therefore, adds a small 


degree of credibility to the data. 



Finance 

90.0 

Top Communication Users 

Communications 

85.0 

Government 

78.0 


Military 

66.0 


Publishing 

62.0 


Energy 

25.5 

Bottom Communication Users 

Food Service 

23.0 


Construction 

17.5 


Recreation 

17.0 


Utility 

15.0 



3.2.4 Application versus Time Database (SCAR DB4) 

This database. Table 3.2.4- 1, "Applications vs Time Database", associates daily time-slots 
for issuing ISDN service requests on an application basis. This data allows the generation 
of traffic distributions that are appropriate to the application being used in a scenario. The 
hours in a day are divided into four unequal time slots along the line of a typical work day: 
0001-0800, 0801-1200, 1201-1800, and 1801-2400. The applications are distributed in 
the same normalized fashion as described before. This database shows that these 8, 4, 6, 
and 6 hour-periods break up the communication day into the following comparative 
importance: 79.5, 252.9, 392.0, and 176.5 according to their Communications Check 
Sum. These data indicate that most communication traffic is sent between 1201 and 1800 
hours, local time. 

3.2.5 Application vs ISDN Bearer Service Database (SCAR DB5) 

This database. Table 3.2.5- 1, "Application vs ISDN Bearer Service, Message Length 
Database", associates ISDN bearer services with the selected scenario applications. For 
this SCAR program the following ISDN bearer services have been selected: circuit 
switched (64 kbps and 128 kbps), D-Channel X.25, B-Channel Frame Relay, and 
Telemetry. The applications are distributed among these ISDN services in the same 
normalized fashion as before. The Communications Check Sum indicate the relative 
demands on these ISDN bearer services: 


CS64 KBPS 

415.0 

CS128KBPS 

155.0 

DX25 

152.0 

BFRAMERELY 

123.0 

TELEMETRY 

55.0 
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Table 3.2.4-1 Application vs Time Database 

SCAR Database 4 


APPLICATION 

0001-0800 
midl8am 
8 hours 
TIMENOl 

% 

0801-1200 

8am/ noon 
4 hours 
TIMENOl 

% 

1201-1800 
nooH/6pm 
6 hours 
TIMEN03 

% 

1801-2400 
6pm/ mid 
6 hours 
TIMEN04 

% 

C/uck 

SormaixaHon 

% 

Voice (interactive) 

Voice(message) 

Facsimile 

2.5 

2.5 

2.5 

32.0 

32.0 

32.0 

51.0 

51.0 

51.0 

14.5 

14.5 

14.5 

100.0 

100.0 

100.0 

FileTransfer 

VideoBroadcasting 

VideoConference 

52.0 

10.0 
2.5 

3.0 

25.0 

32.0 

5.0 

30.0 

51.0 

40.0 

35.0 
14.5 

100.0 

100.0 

100.0 

InteractiveData 

Transaction 

Teletex 

Communications Chock Sam: 

2.5 

2.5 

2.5 

79J 

32.0 

32.0 

32.0 

232.0 

51.0 

51.0 
51.0 

392.0 

14.5 

14.5 
14.5 

176.5 

100.0 

100.0 

100.0 

900.0 


900.0 
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This database also associates the message length and message hold-time with each 
application. These message duration values provide a measure of the length of time each 
ISDN bearer service is used. 

3.3 Traffic Model E-R Diagram 

The Traffic Model database is described in terms of an Entity-Relationship diagram. As 
shown in Figure 3.3-1, "NASA SCAR E-R Diagram for Traffic Model", six entities are 
joined with relative simple relationship to form the data model for the SCAR Traffic Model. 
In this entity-relationship diagram, cities are identified with industries that have applications 
that, in turn, have time slot, bearer service, and message duration relationships. The text 
adjacent to the entity boxes and relationship nodes contain the name of the corresponding 
Traffic Model database. The number in parentheses indicates the number of data elements 
in that database. The number inside each entity box indicates the record count for that 
entity. The corresponding Traffic Model data elements describe the entity they represent in 
sufficient detail to generate a family of scenarios for any ISDN traffic load. 
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Figure 3.3-1 Entity-Relationship Diagram for the NASA SCAR Traffic Model 





SECTION 4 


SCANARIO GENERATION 

4.1 Scenario Generation Process 

The scenario generation process uses the data from the Traffic Model database, described in 
Section 3.0 to generate a scenario traffic file (STF) of initial discrete events for the discrete 
event simulations described in Section 2.2.3. The STF consists of a time-ordered list of 
requests for a service and a release of that service when completed. For example, The STF 
discrete event requesting a circuit-switched B-Channel from Baltimore to Chicago at 0800 
am looks like: 

Time CallRef# Action Resources OrigCity DestCity 

0800 1012 Rqst CS64 Balt Chi 

The corresponding discrete event terminating this call, 31 minutes after its initiation, looks 
like: 

Time CallRef# Action 

0831 1012 Term 

In the STF discrete event terminating service the unique CallRef# is sufficient to identify 
the service being terminated. 

4.2 Scenario Generation Algorithm 

The scenario generation program takes the data from the Traffic Model database and 
generates the corresponding STF entries. For example, to generate ISDN calls from 
Baltimore to Chicago the scenario script must have selected these two cities and possibly 
other cities. The following algorithm generates the associated ISDN service requests: 

1 . From SCAR DB 1 the population of Baltimore is cited as 2,342,000 with 
3.2% of them being daily ISDN users. Therefore, the number of daily 
ISDN service calls from Baltimore is 74,994. 

2. If the scenario script selected, only the following Baltimore industries 
having the corresponding ISDN percentages in SCAR DB2 then the total 
daily ISDN service calls from Baltimore by industries would amount to: 


ISDN% 

Broadcast 4.0% 

Communication 10.0% 

Education 6.0% 


ISDN Calls 
2,998 
7,494 
4,497 


3 . If the scenario script further restricted the applications to Voice(Interactive), 
Voice(Message), and Facsimile, then these Baltimore ISDN service calls are 
further partitioned by this matrix from SCAR DB3: 
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Voice© 

Voice(M) 

Facsimile 

Broadcast 

3.0% 

0.5% 

1.0% 

Communication 

6.0% 

5.0% 

10.0% 

Education 

5.0% 

5.0% 

5.0% 

suiting ISDN service calls from Baltimore in term of those 

dons are: 

Voice© 

Voice(M) 

Facsimile 

Broadcast 

90 

15 

30 

Communication 

450 

375 

750 

Education 

225 

225 

225 


4. If the scenario script again further restricts the applications to following 
bearer services: CS64KBPS, CS128KBPS, and DX25 as cited in SCAR 
DB5, then the following Baltimore ISDN service calls are associated with 
the ISDN bearer services: 


Voice(Inter active) 

CS 64KB PS 

100 % 

CS128KBPS 

0 % 

DX25 

0 % 

Broadcast 

90 

0 

0 

Communication 

450 

0 

0 

Education 

225 

0 

0 

Voice(Message) 

CS64KBPS 

100 % 

CS128KBPS 

0 % 

DX25 

0 % 

Broadcast 

90 

0 

0 

Communication 

450 

0 

0 

Education 

225 

0 

0 

Facsimile 

CS64KBPS 

80 % 

CS128KBPS 

15 % 

DX25 

2% 

Broadcast 

72 

2 

1 

Communication 

360 

56 

15 

Education 

180 

34 

5 


5. These three applications have the same call distribution over time, see 
SCAR DB4: 


Time 

0001- 

0801- 

1201- 

1801- 

(hours) 

0800 

1200 

1800 

2400 

Time 1 

Time 2 

Time 3 

Time 4 

Voice(Interactive) 

2.5% 

32.0% 

51.0% 

14.5% 

Voice(Message) 

2.5% 

32.0% 

51.0% 

14.5% 

Facsimile 

2.5% 

32.0% 

51.0% 

14.5% 


The number of calls in each time slots T1/T2/T3/T4 for each Baltimore ISDN service call 
category is: 


4-2 



CS64KBPS 

CS 128KBPS 

DX25 

Voice(Interactive) 

100% 

0% 

0% 

Broadcast 

90 

0 

0 


2/29/46/13 

o/o/o/o 

o/o/o/o 

Communication 

450 

0 

0 


11/144/230/65 

o/o/o/o 

o/o/o/o 

Education 

225 

0 

0 


6/72/114/33 

o/o/o/o 

o/o/o/o 


CS64KBPS 

CS128KBPS 

DX25 

Voice(Message) 

100% 

0% 

0% 

Broadcast 

90 

0 

0 


2/29/46/13 

o/o/o/o 

o/o/o/o 

Communication 

250 

0 

0 


6/77/122/35 

o/o/o/o 

o/o/o/o 

Education 

225 

0 

0 


6/ 72/114/33 

o/o/o/o 

o/o/o/o 


CS64KBPS 

CS128KBPS 

DX25 

Facsimile 

80% 

15% 

2% 

Broadcast 

72 

2 

1 


2/23/37/10 

0/1/1/0 

0/0/1/0 

Communication 

360 

56 

15 


9/115/184/52 

2/18/28/8 

0/5/8/2 

Education 

180 

34 

5 


5/58/91/26 

1/11/7/5 

0/2/2/1 


Within each of these time-slots the ISDN service calls are assumed to be uniformly 
distributed. In our example, the 90 ISDN voice(interactive) calls from Baltimore that are 
associated with the broadcast industry that use the CS64KBPS ISDN bearer service fall 
into a 2/29/46/13 time-slot distribution pattern. This means that : 

2 ISDN call will be selected from a uniform distribution between 0001-0800 hrs, 

29 ISDN calls will be selected from a uniform distribution between 0801-1200 hrs, 

46 ISDN calls will be elected from a uniform distribution between 1201-1800 hrs, and 
13 ISDN calls will be selected from a uniform distribution between 1801-2400 hrs. 

A sequence number is produced by the ScenGen program to uniquely identify each call. 
The resulting STF for initiating these 90 ISDN voice(interactive) calls from Baltimore could 
look like: 
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Time 

CallRef 

Action 

Rersour 

OrigCity DestCity 

0700 

0001 

Rqst 

CS64 

Balt * where: 

* = represents a city selected from a uniform distribu- 
tion of those cities selected by the scenario script. 

0815 

0002 

Rqst 

CS64 

Balt 

* 

0830 

0003 

Rqst 

CS64 

Balt 

* 

1148 

0015 

Rqst 

CS64 

Balt 

* 

1215 

0016 

Rqst 

CS64 

Balt 

* 

1232 

0017 

Rqst 

CS64 

Balt 

* 

2347 

0090 

Rqst 

CS64 

Balt 

* 


6. The length of time associated with the use of these ISDN bearer services is 
proportional to the hold-time for that service. SCAR DB5 cites these hold- 
times as a function of the application. For our example of the 90 
CS64KBPS voice(interactive) calls the hold-time is 3 minutes. Using a 
uniform distribution with a parametric value of 3, hold-times are determined 
for each ISDN call request. That hold-time is added to the call request event 
time to determine the call termination event time. The resulting STF is 
shown below. The unique CallRef# is sufficient to handle the disconnect 
request. 


Time 

CallRef 

Action 

Rersour 

OrigCity DestCity 

0700 

0001 

Rqst 

CS64 

Balt * where: 

0702 

0001 

Term 


* = represents a city selected from a uniform distribu- 
tion of those cities selected by the scenario script. 

0815 

0818 

0002 

0002 

Rqst 

Term 

CS64 

Balt * 

0830 

0831 

0003 

0003 

Rqst 

Term 

CS64 

Balt * 

1158 

1201 

0015 

0015 

Rqst 

Term 

CS64 

Balt * 

1215 

1218 

0016 

0016 

Rqst 

Term 

CS64 

Balt * 

1232 

1233 

0017 

0017 

Rqst 

Term 

CS64 

Balt * 

1749 

1750 

0038 

0038 

Rqst 

Term 

CS64 

Balt * 

1816 

1818 

0039 

0039 

Rqst 

Term 

CS64 

Balt * 

1915 

1918 

0040 

0040 

Rqst 

Term 

CS64 

Balt * 

2347 

2349 

0090 

0090 

Rqst 

Term 

CS64 

Balt * 


4-4 


4.3 


Scenario Generation Results 


This STF suitably represents the ISDN user traffic for the SCAR network model and 
discrete event simulation. There are sufficient degrees of freedom to permit a number of 
tailored scenarios to determine the ISDN communications satellite design parameter limits, 
test subsystems and procedure and stress the overall system. An example of scenario 
profile for four cities: Baltimore, Chicago, Los Angeles, and San Francisco using the 
industries of broadcast, construction, communications, data processing, and education 
across all bearer services is shown in Figure 4.3-1, "Scenario Generation Example". 
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Figure 4.3-1 Scenario Generation Example 





SECTION 5 

APPLICATION OF TRAFFIC MODEL TO SCENARIOS 


5.1 Scenario Scripts 

Scenario scripts consist of descriptive text that presents the objectives, goals, strategy, and 
the selected scenario components that are to be used to generate a given scenario. These 
scenario scripts are used in conjunction with the ScenGen program and the Traffic Model 
database. Each scenario has a reason for being. They address a specific aspect of the 
NASA SCAR design for an advanced ISDN communications satellite. The ISDN 
communication satellite topology, design parameters, and environment are part of the 
simulation initial conditions. The subsequent Traffic Model scenario discrete events 
requesting and relinquishing ISDN bearer services act in concert with these design 
parameters. 


5.2 Scenario Scripts Types 

Four types of scenarios will be used in the NASA SCAR Program: checkout, baseline, 
stress, and special scenarios. A checkout scenario w ill be used to verify the functionality 
of various sets of ISDN subsystems of the satellite design. The objectives are to quickly 
and easily demonstrate that the actions and protocols that accompany a specific ISDN 
bearer service are modeled and simulated properly and are operating as described in the 
standards. Five checkout scenarios are planned for this NASA SCAR Program: CS64, 
CS128, DX25, BFRAMERELY, and TELEMETRY. These checkout scenario address the 
bearer services that are identified in the Traffic Model database. 

A baseline scenario will be used as a standard for all NASA SCAR Program simulations. 
The purpose is to provide a benchmark that will produce comparable results as the 
advanced ISDN communications satellite design evolves. This baseline scenario should 
include a sufficient variety of ISDN Traffic Model to adequately gauge the satellite design. 

Stress scenarios will be developed to determine the limits of the ISDN communications 
satellite design. The objective is to find the break points in the design in order to determine 
the engineering and operating envelop for the system. Three stress scenarios are planned: 
traffic stress, environment stress, and link breakdown stress. The traffic stress scenario 
will use a message scale factor to systematically increase the traffic cited in the Traffic 
Model until a failure occurs. The environment stress scenario will systematically add 
weather losses to the system to determine the utility of weather mitigating techniques. The 
link-breakdown stress scenario will systematically disable single communication links to 
simulate a link-breakdown in order to determine the system robustness. 

Special scenarios w ill be developed on a demand basis to investigate specific attributes of 
the ISDN communications satellite design and to verify the assumptions used in the Traffic 
Model. At least one special scenario wifi be developed for this NASA SCAR Program 

5.3 Scenario Scripts Options 

The rationale for a scenario script must include a list of Traffic Model database components 
that are to participate in the scenario. Figure 5.3-1, "Scenario Selection Options for the 
Traffic Model", shows the database architecture for the Traffic Model indicating the 
scenario selection options that are available. Once these options are selected, the ScenGen 
program automatically implements the algorithm presented in Section 4.2 to generate a STF 
for the ISDN network model simulation. By selecting combinations of cities, industries, 
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Figure 5.3-1 Scenario Script Selection Options for Traffic Model 




